home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9701 / 000009_owner-linux-arm…r.rutgers.edu _Mon Jan 20 12:48:45 1997.msg < prev    next >
Internet Message Format  |  1998-01-25  |  4KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from nic.funet.fi (nic.funet.fi [128.214.248.6]) by odie.barnet.ac.uk (8.8.2/8.8.0) with ESMTP id MAA27700 for <willy@odie.fluff.org>; Mon, 20 Jan 1997 12:48:43 GMT
  3. Received: from vger.rutgers.edu ([128.6.190.2]) by nic.funet.fi with ESMTP id <66306-8831>; Mon, 20 Jan 1997 14:47:36 +0200
  4. Received: by vger.rutgers.edu id <213091-11748>; Mon, 20 Jan 1997 07:35:21 -0500
  5. Message-Id: <199701201340.NAA23883@spider>
  6. Subject: Re: Arm Linux
  7. To: linux-arm@vger.rutgers.edu
  8. Date:     Mon, 20 Jan 1997 13:40:17 +0000 (GMT)
  9. Reply-To: John.Tytgat@barco.com
  10. From: John.Tytgat@barco.com (John Tytgat)
  11. X-Mailer: ELM [version 2.4 PL23]
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Sender: owner-linux-arm@vger.rutgers.edu
  16. Precedence: bulk
  17. Status: RO
  18.  
  19. From:    ADMVAX::SMTP%"pjb27@cam.ac.uk" 20-JAN-1997 13:36:37.10
  20. To:    OCTAAF::_JOTY
  21. CC:    
  22. Subj:    Re: Arm Linux
  23.  
  24. Date:     Mon, 20 Jan 1997 12:25:15 +0000 (GMT)
  25. From: Philip Blundell <pjb27@cam.ac.uk>
  26. X-Sender: pjb27@hammer.thor.cam.ac.uk
  27. To: Joseph Heenan <esuvf@csv.warwick.ac.uk>
  28. Cc: linux-arm@vger.rutgers.edu
  29. Subject: Re: Arm Linux
  30. In-Reply-To: <28500.199701201213@lupin.csv.warwick.ac.uk>
  31. Message-Id: <Pine.SOL.3.95.970120121454.7874E-100000@hammer.thor.cam.ac.uk>
  32. Mime-Version: 1.0
  33. Content-Type: TEXT/PLAIN; charset=US-ASCII
  34. Sender: owner-linux-arm@vger.rutgers.edu
  35. Precedence: bulk
  36.  
  37. On Mon, 20 Jan 1997, Joseph Heenan wrote:
  38.  
  39. > Perhaps I've got the wrong end of the stick here - I'd assumed
  40. > debian would be a lot of C sources that just need perhaps the odd
  41. > bit of inline assembler rewriting. Surely the C compiler should handle
  42. > all the platform specific things, apart from inline assembler?
  43.  
  44. No.  To take a contrived example, imagine you have this:
  45.  
  46. unsigned char foo[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
  47. unsigned int *bar;
  48.  
  49. bar = (unsigned int *)(foo+1);
  50. printf("bar = %08x\n", *bar);
  51.  
  52. On Intel, this gives:
  53.  
  54. kings-cross:~$ ./align
  55. bar = 05040302
  56. kings-cross:~$
  57.  
  58. On Alpha, this gives:
  59.  
  60. paddington:~$ ./align 
  61. align(1964): unaligned trap at 0000000120000a74: 000000011ffff711 28 2
  62. bar = 05040302
  63. paddington:~$
  64.  
  65. But on an old ARM, you will get `bar = 0x04030201'.  The reason is that
  66. the dereference of `bar' compiles to an LDR instruction.  In general, the
  67. compiler can't know the alignment at compile-time, so there's not a lot
  68. else it *can* do.  Old ARM machines silently discard the low two address
  69. bits when you ask them to do a word access.  This differs, as I said
  70. before, from the Intel (where you get the correct access performed, albeit
  71. more slowly) and the Alpha/SPARC/etc (where you get a fault, and your OS
  72. has to patch up in software).
  73.  
  74. This sort of thing doesn't crop up *that* often, but it does happen, and
  75. code will go wrong when it does.  There is *very* little inline assembler
  76. in most things, and I doubt much porting work will be needed in general.
  77. A lot of autoconf scripts will probably need to be taught about Linux/ARM,
  78. but other than that...
  79.  
  80. > Basic sounds like quite a good idea. Shame it's copyright, really -
  81. > a basic interpretter running under general unix has some sort of appeal
  82. > to it :-)
  83.  
  84. Yes.  OTOH, although it's copyright, if it's in ROM it can be used fairly
  85. freely.  Someone sufficiently sick could probably write a snippet of code
  86. to be run as root that rummages around the RISC OS ROMs and pulls out the
  87. BASIC module. 
  88.  
  89. P.